-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, AM4CaXJzg1GybpwYhGOTjv8a9e6MGgSliPpS9AMFl3CrA5gh0BRSVDpdHNCfo0IM KJxOyLH+eikjWxsIEUQpvo0= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED I've been too busy lately to keep up with bugtraq on a real-time basis, so this is pretty delayed. Darren Bock wrote on 12/12/94: > > While this is old news to anyone that has been around the traps for a while > it was interesting to see that DEC OSF V3.0 has repeated the mistakes of > people like SCO by creating files that contain security information that > are not owned by root.... > > Under OSF V3.0 there can be a small trap with the C2 security if you also use > NFS > > 'Lionel Provost' (on the alpha-osf-managers@ornl.gov list) said : > > > > But , if you have the C2 Security installed you could always > > modify /etc/passwd, it doesn't work because /etc/passwd is in > > yhis case a mirror of a database which is in /tcb/files/auth... > > > > This supposed security setup is a bit like what SCO did when they started > using (in)secureware. The one minor problem with the method used to implement > this idea is that root no longer owns these files. > > If you are silly enough (or by mistake) to allow your "/" filesystem to be NFS > exported it is fairly trivial for anyone to give themselves root privs on your > system (in this C2 setup). > > I have seen people with SCO systems allow unrestricted NFS export on all their > filesystems (including / and /usr). One particular person went on holidays and > forgot his root password, I used this particular trick as an easy way to reset > the root password, it took 3 minutes all up (quicker than a reboot off floppy) Being from SecureWare, I feel the need to respond. The specific attack Darren mentions is quite accurate, and is unique to operating systems based upon SecureWare technology. The hole, however, i.e. being stupid enough to export your root filesystem, is common across all variants of Unix. If you are running Unix and you allow export of "/", it is trivial to gain root access to your system through any number of attacks -- even if you remap uid 0 to "anonymous". NOTE that on many older systems it is not sufficient to restrict export of "/" to read-only. Sun's NFS 3.X code had a bug in the rename operation that failed to check for read-only on the target path's export information. Most vendors missed this and incorporated it into their ports. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE-----